When developing or customizing a software system that provides business functionality for business users, one of the problems involves coordination between business analysts and software system analysts. Business analysts are users who are familiar with the required business functionality that the software must provide. Software system analysts design or customize software systems to provide the required business functionality. Frequently, the business analysts view the business functionality at a level of abstraction which is much higher than the level of abstraction at which the software system requirements must be specified by the software system analysts. Furthermore, once the software system has been developed and deployed, those concerned with the deployment and maintenance of the software system (typically, system administrators and/or operators) view the software system at an even lower level of abstraction than that of the system analysts.
Therefore, in the lifecycle of a software system development and deployment, there is no simple mechanism to coordinate the views of the software system for these analysts that view the software system from different perspectives and different levels of abstraction. Therefore, business analysts and software system analysts lack a convenient mechanism by which changes at one level of abstraction are correlated to changes at a different level of abstraction so that the impact of the changes at one level of abstraction can be conveniently analyzed at another level of abstraction.
In order to facilitate rapid software application development, there are tools for creating or facilitating the creation of software applications from a business perspective. These tools are typically model driven and utilize a proprietary runtime environment for the created software application. Furthermore, in many cases, the models that are used are created using proprietary modeling tools. The business rules are developed in the model and these rules together with the other model attributes may then be used to generate the high level software application logic. The tools then use the business rules and the other model attributes to generate the lower level application logic and the corresponding program code either automatically or with partial input from a system developer. However, the lower level application logic or the program code is typically not suitably connected to the higher level business model rules or artifacts at a level of detail that ties in runtime parameters and data of the software application to the business model rules and artifacts that were used to generate the software application. Therefore, there are no views to link the generated program code and the software application run time parameters to the business model artifacts and rules on an ongoing basis. That is, these tools are not designed to be used on an ongoing basis by business analysts to analyze the ongoing performance of the software application—they merely provide an interface to define business rules that are then used by a software system analyst to define and generate the lower level application logic and program code modules. These lower level application logic and program code are not tied back to the business model rules or artifacts in a meaningful way to facilitate a business level analysis on an ongoing basis during the runtime of the software application.